#There is a cyclic dependency between:
`dataset.h -> common.h -> randomx.h -> dataset.h`
As a fix, we should not include randomx.h in common.h, as it makes the least
sense there.

#This is very weird (common.hpp):
`typedef void(DatasetDeallocFunc)(randomx_dataset*);`
This seems to be used when defining `struct randomx_dataset`, that means it is
calling itself before being defined?

Functions `randomx_alloc_cache`, `randomx_alloc_dataset`, etc. have moved
their declarations to `dataset.h` from `randomx.h` and renamed to i.e.
`randomx_dataset_alloc`, `randomx_dataset_alloc_cache`.

Functions `randomx_create_vm`, etc. have moved their declaration to
`virtual_machine.h` and renamed to i.e. `vm_create`.

`argon2` and `blake2` functions will not get `randomx_` prefix.

`randomx_dataset` type has changed from a struct to `uint8_t *` which is just a
memory pointer.

`programs` of `randomx_dataset_cache` struct has changed type
from `randomx_SuperscalarProgram a[]` to `randomx_SuperscalarProgram *a[]` to
avoid copying memory.

Implemented the `aes_hash` header file that does not exit in the original
implementation as it defines templates that do not need header definitions.


#Text below should be properly formatted

originally, the dataset.h file defines both dataset and cache functions, but
the dataset functions only accept cache as the argument. Furthermore, randomx.h
defines allocations and initializations for dataset (which has both dataset and
cache as argument) and cache (which only has cache as argument).

I don't know for sure why these functions are defined in randomx.h, I can guess
that it has something to do with randomx_flags, which can easily be included in
elsewhere (i think).

To make things more readable, we can make 2 header files, dataset and cache,
and make dataset include cache, as it needs it in some functions. Cache, however,
does not seem to need the dataset struct (which we may change to just be a uint8_t
pointer, getting rid of the function pointer inside a struct, which has
performance implications)


```
inline rx_vec_i128 aesdec(rx_vec_i128 in, rx_vec_i128 key) {
	return soft ? soft_aesdec(in, key) : rx_aesdec_vec_i128(in, key);
}
```
Thought about changing this functionality, but, as the added complexity is very
high and the performance gains are minimal, we will keep this the same way.
